Architectures, Coordination, and Distance: Conway's Law and Beyond

S e p t e m b e r / O c t o b e r 1 9 9 9 I E E E S o f t w a r e 6 3 Software engineering researchers have long argued that the architecture of a system plays a pivotal role in coordinating development work. Over 30 years ago, Melvin Conway proposed what has since become known as Conway’s Law—that the structure of the system mirrors the structure of the organization that designed it.1 This relation, Conway argued, is a necessary consequence of the communication needs of the people doing the work. David Parnas, in fact, defined a software module as “a responsibility assignment rather than a subprogram,”2 driving home the idea that modular design enables decisions about the internals of each module to be made independently. Of course, the computer that runs the software doesn’t care. The point of structure is to support coordination of the development work. Architecture, however, addresses only one of the several dimensions on which we must coordinate development. To support efficient use of resources, projects require plans that specify when milestones must be completed and who will do the Architectures, Coordination, and Distance: Conway’s Law and Beyond G eographica l ly d i s t r ibuted deve lopment teams face ex t raord inar y communicat ion and coord inat ion problems. The authors’ case s tudy c learly demonst rates how common but unant ic ipated events can st retch pro jec t communicat ion to the break ing p o int. Pro jec t schedules can fa l l apar t, par t i cu larly dur ing integrat ion . Mo dular des ign i s necessar y, but not su f f i c ient to avo id th i s fa te.